A computer network typically comprises a plurality of interconnected entities that transmit (“source”) or receive (“sink”) data frames. A common type of computer network is a local area network (“LAN”) that generally comprises a privately owned network within a single building or campus. LANs employ a data communication protocol (LAN standard) such as Ethernet, FDDI, or Token Ring, that defines the functions performed by the data link and physical layers of a communications architecture (i.e., a protocol stack), such as the Open Systems Interconnection (OSI) Reference Model. In many instances, multiple LANs may be interconnected by point-to-point links, microwave transceivers, satellite hookups, etc., to form a wide area network (“WAN”), metropolitan area network (“MAN”) or Intranet. These internetworks may be coupled through one or more gateways to the global, packet-switched internetwork generally known as the Internet or World Wide Web (WWW).
Each network entity preferably includes network communication software, which may operate in accordance with Transport Control Protocol/Internet Protocol (TCP/IP). TCP/IP generally consists of a set of rules defining how entities interact with each other. In particular, TCP/IP defines a series of communication layers, including a transport layer and a network layer. At the transport layer, TCP/IP includes both the User Data Protocol (UDP), which is a connectionless transport protocol, and TCP, which is a reliable, connection-oriented transport protocol. When a process at one network entity wishes to communicate with another entity, it formulates one or more messages and passes them to the upper layer of the TCP/IP communication stack. These messages are passed down through each layer of the stack where they are encapsulated into packets and frames. Each layer also adds information in the form of a header to the messages. The frames are then transmitted over the network links as bits. At the destination entity, the bits are re-assembled and passed up the layers of the destination entity's communication stack. At each layer, the corresponding message headers are stripped off, thereby recovering the original message that is handed to the receiving process.
One or more intermediate network devices are often used to couple LANs together and allow the corresponding entities to exchange information. For example, a bridge may be used to provide a “bridging” function between two or more LANs. Alternatively, a switch may be utilized to provide a “switching” function for transferring information, such as data frames or packets, among entities of a computer network. Typically, the switch is a computer having a plurality of ports that couple the switch to several LANs and to other switches. The switching function includes receiving data frames at a source port and transferring them to at least one destination port for receipt by another entity. Switches may operate at various levels of the communication stack. For example, a switch may operate at Layer 2, which in the OSI Reference Model, is called the data link layer, and includes the Logical Link Control (LLC) and Media Access Control (MAC) sub-layers.
Other intermediate devices, commonly known as routers, may operate at higher communication layers, such as Layer 3, which in TCP/IP networks corresponds to the Internet Protocol (IP) layer. Conventionally, IP data packets include a corresponding header that contains an IP source address and an IP destination address. Routers or Layer 3 switches may re-assemble or convert received data frames from one LAN standard (e.g., Ethernet) to another (e.g., Token Ring). Thus, Layer 3 devices are often used to interconnect dissimilar subnetworks. Some Layer 3 intermediate network devices may also examine the transport layer headers of received messages to identify the corresponding TCP or UDP port numbers being utilized by the corresponding network entities. Many applications are assigned specific, fixed TCP and/or UDP port numbers in accordance with Request For Comments (RFC) 1700. For example, TCP/UDP port number 80 corresponds to the Hypertext Transport Protocol (HTTP), while port number 21 corresponds to File Transfer Protocol (FTP) service.
A process executing at a network entity may generate hundreds or thousands of traffic flows that are transmitted across a network. Generally, a traffic flow is a set of messages (frames and/or packets) that typically correspond to a particular task, transaction or operation (e.g., a print transaction) and may be identified by various network and transport parameters, such as source and destination IP addresses, source and destination TCP/UDP port numbers, and transport protocol.
The treatments that are applied to different traffic flows may vary depending on the particular traffic flow at issue. For example, an online trading application may generate stock quote messages, stock transaction messages, transaction status messages, corporate financial information messages, print messages, data backup messages, etc. A network administrator may wish to apply a different policy or service treatment (“quality of service” or “QoS”) to each traffic flow. In particular, the network administrator may want a stock quote message to be given higher priority than a print transaction. Similarly, a $1 million stock transaction message for a premium client should be assigned higher priority than a $100 stock transaction message for a standard customer.
Computer networks include numerous services and resources for use in moving traffic throughout the network. For example, different network links, such as Fast Ethernet, Asynchronous Transfer Mode (ATM) channels, network tunnels, satellite links, etc., offer unique speed and bandwidth capabilities. Additionally, the intermediate devices also include specific resources or services, such as number of priority queues, filter settings, availability of different queue selection strategies, congestion control algorithms, etc.
Individual frames or packets can be marked so that intermediate devices may treat them in a predetermined manner. For example, the Institute of Electrical and Electronics Engineers (IEEE) describes additional information for the MAC header of Data Link Layer frames in Appendix 802.1p to the 802.1D bridge standard.
A Differentiated Services (DS) model is under development by the Internet Differentiated Services Working Group of the Internet Engineering Task Force (IETF). IETF is seeking to promote DS as the “right” approach for implementing scalable service differentiation in large networks. Network devices that implement DS are said to form a DS domain. Such devices may include routers and switches.
The DS model comprises a number of functional elements that are implemented in network nodes. These functional elements include a small set of per-hop forwarding behaviors (PHBs) that routers or switches may apply to packets, packet classification functions, and traffic conditioning functions, including metering, marking, shaping and policing functions. The DS architecture achieves scalability by implementing complex classification and conditioning functions only at network nodes located at network boundaries, and by applying specified per-hop behavior to aggregates of traffic which have been appropriately marked using the DS field in the IP version 4 (“IPv4”) or IPv6 headers. The PHBs are defined to permit a reasonably granular means of allocating buffer and bandwidth resources at each node among competing traffic streams.
Information about DS may be found in: D. Grossman, “New Terminology for Diffserv,” draft-ietf-diffserv-new-terms-02.txt, November, 1999; V. Jacobson et al., “An Expedited Forwarding PHB,” RFC 2598, June 1998; F. Baker et al., “Management Information Base for the Differentiated Services Architecture,” draft-ietf-diffserv-mib-02.txt, March, 2000; J. Heinanen et al., “Assured Forwarding PHB Group,” RFC 2597, June, 1999; S. Blake et al., “An Architecture for Differentiated Services,” RFC 2475, December, 1998; S. Brim et al., “Per Hop Behavior Identification Codes,” RFC 2836, May 2000; “Differential Service for the Internet,” available at the “diffserv.lcs.mit.edu” Web site; J. Wroclawski, “Applications, Flexibility, and Differential Services,” May, 1998, available in the Web site document “internet2.edu/qos/may98Workshop/presentations/Wroclawski/sld001.htm”; A. Campbell, “Differential Services: Services and Mechanisms, Lecture 11,” Jan. 13, 2000, available in the Web site document “comet.ctr.columbia.edu/distributed/lectures/lecture11/sld001.htm.”
In general, the network administrator is responsible for defining the QoS provided within a network. A network administrator cannot be expected to understand all of the details that are required to modify the schema for an appropriate per-hop-behavior configuration that is effective across the network. In the current DS model, there is no simple way for an administrator to specify the relationship and interdependencies between the different PHBs that are in effect in the DS domain. In particular, there is no simple way to allocate network resources to each PHB in a device independent way.
Based on the foregoing, there is a clear need for a mechanism that can enable a network administrator to define a network-wide specification of QoS PHBs deployed within a DS domain.
There is also a need for a mechanism will allow a network administrator to define the relationship and interdependencies between the different per-hop-behaviors within a DS domain.
There is also a need for a mechanism for providing consistent per-hop-behavior device configuration derived from the network-wide PHB specification thus ensuring end-to-end enforcement of the QoS PHBs.
The current DS approach does allow definition of relationships between the different PHBs within an AF PHB group, but it does not provide an easy way to define the relationship between resources allocated to the entire PHBs enforced on the domain. In particular, it does not provide a way to specify the relationship between the AF PHB groups and the relationship to the EF and BE PHBs or any user-defined PHB. In particular, there is a need for a way to guarantee minimal bandwidth and buffer resources to each PHB as well as to limit a PHB from exploiting more than its share in these resources.
There is also a need for a way to automatically generate device configuration parameters for the PHBs so that device behavior matches the definition of the PHB.